Package | hl7.ehrs.ehrsfmr21 |
Type | Requirements |
Id | Id |
FHIR Version | R5 |
Source | http://hl7.org/ehrs/https://build.fhir.org/ig/mvdzel/ehrsfm-fhir-r5/Requirements-EHRSFMR2.1-TI.1.7.html |
Url | http://hl7.org/ehrs/Requirements/EHRSFMR2.1-TI.1.7 |
Version | 2.1.0 |
Status | active |
Date | 2024-11-26T16:30:50+00:00 |
Name | TI_1_7_Secure_Data_Routing |
Title | TI.1.7 Secure Data Routing (Function) |
Experimental | False |
Realm | uv |
Authority | hl7 |
Description | Route electronically exchanged EHR data only to/from known and authenticated destinations/sources (according to applicable healthcare-specific rules and relevant standards). |
Purpose | An EHR-S needs to ensure that it is exchanging EHR information with the entities (applications, institutions, directories) it expects. This function depends on entity authorization and authentication to be available in the system. For example, a physician practice management application in an EHR-S might send claim attachment information to an external entity. To accomplish this, the application must use a secure routing method, which ensures that both the sender and receiving sides are authorized to engage in the information exchange. Known sources and destinations can be established in a static setup or they can be dynamically determined. Examples of a static setup are recordings of IP (Internet Protocol) addresses or recordings of DNS (Domain Name System) names. For dynamic determination of known sources and destinations, systems can use authentication mechanisms as described in TI.1. For example, the sending of a laboratory order from the EHR-S to a laboratory system within the same organization usually uses a simple static setup for routing. In contrast, sending a laboratory order to a reference laboratory outside of the organization will involve some kind of authentication process. Provision of a secure network infrastructure is beyond the scope of an EHR-S. |
No resources found
No resources found
Note: links and images are rebased to the (stated) source
Route electronically exchanged EHR data only to/from known and authenticated destinations/sources (according to applicable healthcare-specific rules and relevant standards).
An EHR-S needs to ensure that it is exchanging EHR information with the entities (applications, institutions, directories) it expects. This function depends on entity authorization and authentication to be available in the system. For example, a physician practice management application in an EHR-S might send claim attachment information to an external entity. To accomplish this, the application must use a secure routing method, which ensures that both the sender and receiving sides are authorized to engage in the information exchange. Known sources and destinations can be established in a static setup or they can be dynamically determined. Examples of a static setup are recordings of IP (Internet Protocol) addresses or recordings of DNS (Domain Name System) names. For dynamic determination of known sources and destinations, systems can use authentication mechanisms as described in TI.1. For example, the sending of a laboratory order from the EHR-S to a laboratory system within the same organization usually uses a simple static setup for routing. In contrast, sending a laboratory order to a reference laboratory outside of the organization will involve some kind of authentication process. Provision of a secure network infrastructure is beyond the scope of an EHR-S.
TI.1.7#01 | SHALL |
The system SHALL conform to function [[TI.1.1]] (Entity Authentication) to exchange EHR data only to and from known, authenticated sources and destinations. |
TI.1.7#02 | SHALL |
The system SHALL conform to function [[TI.2]] (Audit) to capture audit information about changes to the status of sources and destinations. |
{
"resourceType" : "Requirements",
"id" : "EHRSFMR2.1-TI.1.7",
"meta" : {
"profile" : [
"http://hl7.org/ehrs/StructureDefinition/FMFunction"
]
},
"text" : {
"status" : "extensions",
"div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\">\n <span id=\"description\"><b>Statement <a href=\"https://hl7.org/fhir/versions.html#std-process\" title=\"Normative Content\" class=\"normative-flag\">N</a>:</b> <div><p>Route electronically exchanged EHR data only to/from known and authenticated destinations/sources (according to applicable healthcare-specific rules and relevant standards).</p>\n</div></span>\n\n \n <span id=\"purpose\"><b>Description <a href=\"https://hl7.org/fhir/versions.html#std-process\" title=\"Informative Content\" class=\"informative-flag\">I</a>:</b> <div><p>An EHR-S needs to ensure that it is exchanging EHR information with the entities (applications, institutions, directories) it expects. This function depends on entity authorization and authentication to be available in the system. For example, a physician practice management application in an EHR-S might send claim attachment information to an external entity. To accomplish this, the application must use a secure routing method, which ensures that both the sender and receiving sides are authorized to engage in the information exchange. Known sources and destinations can be established in a static setup or they can be dynamically determined. Examples of a static setup are recordings of IP (Internet Protocol) addresses or recordings of DNS (Domain Name System) names. For dynamic determination of known sources and destinations, systems can use authentication mechanisms as described in TI.1. For example, the sending of a laboratory order from the EHR-S to a laboratory system within the same organization usually uses a simple static setup for routing. In contrast, sending a laboratory order to a reference laboratory outside of the organization will involve some kind of authentication process. Provision of a secure network infrastructure is beyond the scope of an EHR-S.</p>\n</div></span>\n \n\n \n\n \n <span id=\"requirements\"><b>Criteria <a href=\"https://hl7.org/fhir/versions.html#std-process\" title=\"Normative Content\" class=\"normative-flag\">N</a>:</b></span>\n \n <table id=\"statements\" class=\"grid dict\">\n \n <tr>\n <td style=\"padding-left: 4px;\">\n \n <span>TI.1.7#01</span>\n \n </td>\n <td style=\"padding-left: 4px;\">\n \n \n \n <span>SHALL</span>\n \n </td>\n <td style=\"padding-left: 4px;\" class=\"requirement\">\n \n <span><div><p>The system SHALL conform to function [[TI.1.1]] (Entity Authentication) to exchange EHR data only to and from known, authenticated sources and destinations.</p>\n</div></span>\n \n \n </td>\n </tr>\n \n <tr>\n <td style=\"padding-left: 4px;\">\n \n <span>TI.1.7#02</span>\n \n </td>\n <td style=\"padding-left: 4px;\">\n \n \n \n <span>SHALL</span>\n \n </td>\n <td style=\"padding-left: 4px;\" class=\"requirement\">\n \n <span><div><p>The system SHALL conform to function [[TI.2]] (Audit) to capture audit information about changes to the status of sources and destinations.</p>\n</div></span>\n \n \n </td>\n </tr>\n \n </table>\n</div>"
},
"url" : "http://hl7.org/ehrs/Requirements/EHRSFMR2.1-TI.1.7",
"version" : "2.1.0",
"name" : "TI_1_7_Secure_Data_Routing",
"title" : "TI.1.7 Secure Data Routing (Function)",
"status" : "active",
"date" : "2024-11-26T16:30:50+00:00",
"publisher" : "EHR WG",
"contact" : [
{
"telecom" : [
{
"system" : "url",
"value" : "http://www.hl7.org/Special/committees/ehr"
}
]
}
],
"description" : "Route electronically exchanged EHR data only to/from known and authenticated destinations/sources (according to applicable healthcare-specific rules and relevant standards).",
"jurisdiction" : [
{
"coding" : [
{
"system" : "http://unstats.un.org/unsd/methods/m49/m49.htm",
"code" : "001",
"display" : "World"
}
]
}
],
"purpose" : "An EHR-S needs to ensure that it is exchanging EHR information with the entities (applications, institutions, directories) it expects. This function depends on entity authorization and authentication to be available in the system. For example, a physician practice management application in an EHR-S might send claim attachment information to an external entity. To accomplish this, the application must use a secure routing method, which ensures that both the sender and receiving sides are authorized to engage in the information exchange. Known sources and destinations can be established in a static setup or they can be dynamically determined. Examples of a static setup are recordings of IP (Internet Protocol) addresses or recordings of DNS (Domain Name System) names. For dynamic determination of known sources and destinations, systems can use authentication mechanisms as described in TI.1. For example, the sending of a laboratory order from the EHR-S to a laboratory system within the same organization usually uses a simple static setup for routing. In contrast, sending a laboratory order to a reference laboratory outside of the organization will involve some kind of authentication process. Provision of a secure network infrastructure is beyond the scope of an EHR-S.",
"statement" : [
{
"extension" : [
{
"url" : "http://hl7.org/ehrs/StructureDefinition/requirements-dependent",
"valueBoolean" : false
}
],
"key" : "EHRSFMR2.1-TI.1.7-01",
"label" : "TI.1.7#01",
"conformance" : [
"SHALL"
],
"conditionality" : false,
"requirement" : "The system SHALL conform to function [[TI.1.1]] (Entity Authentication) to exchange EHR data only to and from known, authenticated sources and destinations.",
"derivedFrom" : "EHR-S_FM_R1.1 IN.1.7#2"
},
{
"extension" : [
{
"url" : "http://hl7.org/ehrs/StructureDefinition/requirements-dependent",
"valueBoolean" : false
}
],
"key" : "EHRSFMR2.1-TI.1.7-02",
"label" : "TI.1.7#02",
"conformance" : [
"SHALL"
],
"conditionality" : false,
"requirement" : "The system SHALL conform to function [[TI.2]] (Audit) to capture audit information about changes to the status of sources and destinations.",
"derivedFrom" : "EHR-S_FM_R1.1 IN.1.7#3"
}
]
}
XIG built as of ??metadata-date??. Found ??metadata-resources?? resources in ??metadata-packages?? packages.